Because debugging and writing debug information to a log file is time consuming and expensive, FormFix provides the ability to control the level of information written to the debug log as well as the ability to turn off writing to a file completely.

Use the objects below to adjust the settings of your debugging, event handling, memory and IDispose for optimal performance.

Control Debugging Information

• Debug - Turns on or off the ability to write to the debug log file.
• DebugLogFile - A filename which stores the debug log information.
• ErrorLevel - Controls the amount of information that is written to the debug log file.

Event Handling

Because event handling is critical to the operation of FormFix, we have implemented several functions that let you test your event-handling code. These are:

Memory Consumption

FormFix relies on an event system and some caching to optimize its use of memory. While this allows FormFix to use as little memory as possible and allows you to manage FormFix's usage of memory, it can result in significant waste of memory if you are not careful.

There are two things of which you should to be especially careful.

1. Properly dispose of objects you are not using anymore by using Dispose() when you are finished using objects. See the IDispose topic below for more information.
2. Be careful of is the template image caching done by FormModel objects. To avoid frequent reloading of template images, FormModel objects often keep an internal copy of template images. If your application works with more than a few FormModel objects and uses RegistrationProcessor or DropOutProcessor objects, you must periodically instruct FormFix to discard the cashed template images. You do this by calling the ReleaseCachedData method. The easiest way to handle this is to call ReleaseCachedData immediately after you finish processing each filled image. That way, you get the benefit of the cached image when processing a bunch of drop-out fields, yet never have more than one cached template image in memory at a time.

A better, but more complex alternative is to keep track of some number of recent forms and release the cached data of forms as you remove them from the recently used list. This allows you to avoid reloading template images for frequently processed forms and it still keeps memory usage to a reasonable limit.

IDispose

One of the most common problems you will run into is proper handling of objects that require explicit disposal. Many of the objects in this component implement the IDisposable interface and you will get best memory utilization if you call each object's Dispose function when you are finished with it. If you have multiple FormFix objects that you need to Dispose of, you can call their Dispose methods in any order. The objects themselves will properly handle all dependencies.

The following Dispose methods are available:

• FormFix.Dispose
• FormImage.Dispose
• FormModel.Dispose
• IdentificationProcessor.Dispose
• IdentificationResult.Dispose
• OMRProcessor.Dispose
• RegistrationProcessor.Dispose
• RegistrationResult.Dispose

The best way to double-check your use of FormFix's disposable objects is to turn on the debug log when your application starts up, then look at the debug log file after your application quits. If you forgot to call a Dispose method, you will see an entry in the debug log like this: "4ec53a8 - 6:51:56:453 - FormImage: Object is being finalized, but should have been Disposed."

You can call any of FormFix's Dispose methods multiple times. The first call will dispose of the resources the object holds and the subsequent calls will be ignored. If you attempt to use an object after you call its Dispose method, it will raise a DisposeException exception.